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BACKGROUND OF THE INVENTION 

Field of the Invention 

The present invention relates generally to computer systems and 
10 software and more particularly to multi-threaded computing. 



Description of the Background Art 

A thread, composed of a context and a sequence of instructions to 
execute, may be defined as an independent flow of control within a process. 

15 The context may comprise a register set and a program counter. 

A thread model operating system is capable of managing single 
threaded as well as multi-threaded processes. As described in Thread Time: A 
Multithreaded Programming Guide" by Scott J. Norton and Mark D. DiPasquale, 
Prentice Hall, 1997, there are different types of thread models. 

20 A many-to-one (Mx1) thread model may also be referred to as a 

user threads implementation. The Mx1 model is implemented in user space and 
does not necessarily require kernel modifications to support single-threaded as 
well as multithreaded processes. In the Mx1 model, there can be many user 
threads, but only one kernel-scheduled entity (i.e. only one kernel thread). When 

25 the kernel scheduler selects a multithreaded process to run, the user scheduler 
in the threads library may plug in the context of the highest priority, runnable 
user thread. The kernel process then executes on behalf of that thread. While 
the kernel views the Mx1 model process as single threaded, the threads library 
scheduler can switch between runnable threads in the process. 

30 A 1x1 thread model (sometimes referred to as NxN) is generally 

implemented in kernel space rather than in user space. Hence, this model may 
be referred to as a kernel threads implementation. In the 1x1 model, there is 
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one kernel thread for every user thread. Each user thread is permanently bound 
to a corresponding kernel-scheduled entity (i.e. to a corresponding kernel 
thread). The kernel thread can execute kernel code or system calls on behalf of 
its corresponding user thread. This model utilizes the kernel scheduler only; the 
5 user space scheduler is not needed. 

The MxN thread model is implemented in both user and kernel 
space. Like the 1x1 model, the MxN model requires kernel modifications and so 
may be referred to as a kernel threads implementation. In the MxN model, there 
can be many user threads and any number of kernel threads. The MxN model 
10 allows user threads to be multiplexed on top of kernel threads or to be bound to 
kernel threads as necessary to suit program requirements. In addition to the 
kernel scheduler, the MxN model utilizes the user space scheduler to schedule 
user threads to run on kernel threads available in the process. The kernel 
scheduler schedules kernel threads to run on processors available in the system. 

SUMMARY 

One embodiment of the invention pertains to a method of obtaining 
status information from user threads of a target process. A system call is 

20 performed from a querying process. The system call creates a kernel debug 
thread in a kernel entity of the target process. The kernel debug thread further 
creates a user status thread in a user entity of the target process. The method 
may be used to obtain the status information without stopping the target process. 
Another embodiment of the invention relates to an operating 

25 system with capability to obtain status information from user threads of a target 
process. The operating system includes at least the following first and second 
system calls. The first system call is configured to create a kernel debug thread 
in a kernel entity of the target process. The second system call is configured to 
awake the kernel debug thread and pass information to the kernel debug thread. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a flow chart depicting a conventional method wherein a 
tracing or debugging tool is used to obtain status data regarding a target 
process. 

FIG. 2 is a flow chart depicting another conventional method 
wherein the target process itself writes logging data. 

FIG. 3 is a schematic diagram depicting an example multi-threaded 
target process. 

FIG. 4 is a flow chart depicting a method for performing a non- 
interfering status inquiry to obtain user thread information in accordance with an 
embodiment of the invention. 

FIG. 5 is a schematic diagram of a querying process and related 
steps in accordance with an embodiment of the invention. 

FIG. 6 is a schematic diagram of the target process and related 
steps in accordance with an embodiment of the invention. 

DETAILED DESCRIPTION 

20 

It is desirable to be able to query the status of user threads in a 
multi-threaded process. The status information can include, but is not limited to, 
the state of individual threads, the registers of individual threads, and process- 
wide information. Unfortunately, conventional techniques for obtaining such 

25 status information typically requires stopping the target process. 

FIG. 1 is a flow chart depicting a conventional method wherein a 
tracing or debugging tool is used to obtain status data regarding a target 
process. In this prior method, the tracing or debugging tool is run 102. The 
querying process of the tool attaches 104 to the target process. By this 

30 attachment to the target process, the target process is halted or stopped. 

Subsequently, commands may be issued 106 to obtain the user thread status 
information. 

FIG. 2 is a flow chart depicting another conventional method 
wherein the target process itself writes logging data. In this prior method, the 
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target program is modified 202 so that it writes out the logging data when it is 
run. For example, instead of linking the target program to the production thread 
library ("libpthread"), the target program may be linked to a special debug library 
("libpthread_tr") which is configured so as to provide the logging functionality. 
5 Thereafter, when the target program is run 204, the logging data is written 206 to 
a known location. This known location may be accessed 208 to obtain the 
logged data. 

FIG. 3 is a schematic diagram depicting an example multi-threaded 
target process 300. User thread status information may be desired from such a 

10 target process 300. The example target process 300 illustrated in FIG. 3 
comprises a process based on an MxN thread model. 

The target process 300 may comprise a target kernel entity 302 in 
kernel space 304 and a target user entity 308 in user space 310. One or more 
target kernel thread(s) 306 may be running in the kernel entity, and one or more 

15 target user thread(s) 312 may be running in the user entity. 

FIG. 4 is a flow chart depicting a method for performing a non- 
interfering status inquiry to obtain user thread information in accordance with an 
embodiment of the invention. The method of FIG. 4 is discussed below in 
conjunction with FIGS. 5 and 6. FIG. 5 is a schematic diagram of a querying 

20 process and related steps in accordance with an embodiment of the invention. 
FIG. 6 is a schematic diagram of the target process and related steps in 
accordance with an embodiment of the invention. 

In one embodiment, a querying process 500 (see FIG. 5) utilizes 
an appropriately configured first kernel interface to issue 402 an inquiry about 

25 the target process. The inquiry may take the form of a system call from a 
querying user thread 508 in the querying user entity 506 to a querying kernel 
thread 504 in the querying kernel entity 502. The system call is configured for 
the querying purpose and creates 404 a kernel debug thread (KDT) 602 (see 
FIG. 6) in the target kernel entity 302 of the target process 300. 

30 The KDT 602 creates 406 a user status thread (UST) 604 in the 

target user entity 308. The UST 604 collects 408 status information from other 
user threads 312 in the target user entity 308. In one embodiment, the UST 604 
may be first created in the kernel as a scheduler activation (SA) and then come 
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up to user space when necessary via a designated upcall handler registered at 
the thread library (libpthread) startup time. An SA comprises a special kernel 
thread in an MxN thread model. The SA has capability to switch between 
different user threads during its lifetime. An upcall handler comprises a 
5 mechanism in an MxN thread model that enables kernel SAs to come up to user 
space and execute body functions of user threads. 

The UST 604 passes 410 the collected user thread information to 
the KDT 602. In one embodiment, a second kernel interface may be configured 
for the UST 604 to communicate 410 the collected information to the KDT 602. 
10 Thereafter, in one embodiment, the UST 604 may go into a "sleep" state until 
awaken by the KDT 602 when a new inquiry comes in. 

The KDT 602 relays 412 the collected information back to the 
querying process 500. In the querying process 500, the relayed information is 
received by the querying kernel thread 504 and passed on to the querying user 
15 thread 508. 

Advantageously, the above-described method does not require 
stopping of the target process 300. Furthermore, if the query is about data other 
than registers, none of the user threads needs to be halted. If the query is about 
a user thread's registers, the UST 604 may issue a thread library API 
20 (application programming interface) call to temporarily suspend the target user 
thread. After reading the target user thread's registers, the UST 604 may issue 
another thread library API call to resume or continue the target user thread. 

Advantageously, the UST 604 may be "invisible" to the user 
threads created by the target application. When the target process 300 exits, the 
25 UST 604 will be terminated. 

In accordance with one embodiment, there is no need to re-create 
the KDT 602 or the UST 604 upon subsequent inquiries. They may go into a 
sleep state such that they can be awaken for those subsequent inquiries. In 
accordance with another embodiment, the KDT 602 and the UST 604 may be 
30 terminated after the inquiry is fulfilled and re-created for subsequent inquiries. 

In accordance with an embodiment of the invention, an operating 
system is modified to implement the above-described method. The operating 
system includes at least the following first and second system calls. The first 
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system call configured to create a kernel debug thread in a kernel entity of the 
target process. The second system call configured to awake the kernel debug 
thread and pass information to the kernel debug thread. In addition, the 
operating system may include a thread library configured to register a user 
5 status thread's stack and data memory and a body function configured to sleep 
until awaken to act upon a user thread status inquiry. 

The above-description describes an embodiment of the invention 
implemented in conjunction with an operating system having an MxN thread 
model. It may also be possible to utilize the invention or aspects thereof with 

10 other thread models. 

In the above description, numerous specific details are given to 
provide a thorough understanding of embodiments of the invention. However, 
the above description of illustrated embodiments of the invention is not intended 
to be exhaustive or to limit the invention to the precise forms disclosed. One 

15 skilled in the relevant art will recognize that the invention can be practiced 

without one or more of the specific details, or with other methods, components, 
etc. In other instances, well-known structures or operations are not shown or 
described in detail to avoid obscuring aspects of the invention. While specific 
embodiments of, and examples for, the invention are described herein for 

20 illustrative purposes, various equivalent modifications are possible within the 
scope of the invention, as those skilled in the relevant art will recognize. 

These modifications can be made to the invention in light of the 
above detailed description. The terms used in the following claims should not be 
construed to limit the invention to the specific embodiments disclosed in the 

25 specification and the claims. Rather, the scope of the invention is to be 

determined by the following claims, which are to be construed in accordance 
with established doctrines of claim interpretation. 
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